Conventional integrated circuit (i.e., chip) input/output (IO) controllers use multi-processor designs that include an input/output processor (IOP) and one or more context manager (CTX) processors. The context managers include the processor and all of the dedicated hardware components of the bus (or protocol) channel. The IOP and each of the CTX processors include dedicated sets of firmware. The IOP (i) receives Message Passing Technology (MPT) request messages from a host operating system (OS) device driver, (ii) performs some processing on the messages, and (iii) transmits the messages to the CTX processors. The context managers handle the dedicated bus protocol (i.e., SCSI, Fibre Channel, Serial ATA, etc.) of the chip. In a dual channel (i.e., dual bus) design, there is a context manager dedicated to each channel.
The OS and the IOP communicate via a set of dedicated system request and system reply first in, first out registers (FIFOs) that are included in the IO controller. In a dual channel controller there is a dedicated set of the system request FIFOs and system reply FIFOs for each peripheral computer interconnect (i.e., PCI, PCI-X, PCI-X DDR, etc.) function. Each PCI function has a one to one relation with a CTX channel: PCI function 0 is dedicated to channel 0 and PCI function 1 is dedicated to channel 1. The IOP receives pointers to messages that are posted by the OS on the system request FIFOs and presents the pointers to the corresponding CTX processor.
Each of the context managers has a dedicated set of inter-processor (IP) queues that are used for communication between the context manager and the IOP. The context managers do not communicate between each other, but only communicate with the IOP. When the IOP has completed processing a request message from the OS, the IOP sends the message to the CTX by posting the message on the inter-processor IO request queue. When the CTX has completed processing the message (or IO), the CTX replies back to the IOP with the status of the IO via the inter-processor IO completion queue. The IOP (i) receives replies from each of the context managers via the IO completion queues, (ii) performs some cleanup, and (iii) sends the status back to the OS via the system reply FIFO.
Referring to FIG. 1, a detailed block diagram illustrating a conventional OS driver and IO controller circuit 10 is shown. The circuit 10 includes an OS driver 12, a PCI bus 14, and an IO controller 16. The host OS device driver 12 is coupled to the IO controller 16 via the PCI bus 14. The OS driver 12 includes a first plurality of message frames 20a–20n, a second plurality of message frames 22a–22n, a first host interface 24, and a second host interface 26. The controller 16 includes a first plurality of PCI function registers 30a–30n, a second plurality of PCI function registers 32a–32n, a request FIFO 34, a message assist engine 36, a free FIFO 38, a plurality of message frames 40a–40n, an IOP 42, a first inter-processor queue that includes an IO request register 44a and an IO completion register 46a, a second IP queue that includes an IO request register 44b and an IO completion register 46b, a first CTX manager 48a, a second CTX manager 48b, a first SCSI core 50a, a second SCSI core 50b, and a reply FIFO 52.
The following steps describe the flow of an IO message between the OS device driver 12, the IOP 40 and the CTX managers 48:
Step A: The host OS driver 12 generates a SCSI (or other appropriate protocol) IO message in the host address space 20.
Step B: The host OS driver 12 posts a system message frame address (SMFA) to the PCI function request register 30 via the host interface 24 and the bus 14.
Step C: The PCI function request register 30 presents the SMFA to the request FIFO 34.
Step D: The request FIFO 34 presents the SMFA to the message assist engine 36.
Step E: The message assist engine 36 waits for a local message frame address (LMFA) in the local message frame 40 to become free.
Step F: The message assist engine 36 presents (i.e., direct memory addresses) the system message frame SMFA to the local message frame 40.
Step G: The message assist engine 36 writes the LMFA to the request FIFO 34.
Step H: The IOP 42 polls the interrupt status register for the request queue (i.e., the free FIFO 38) for a new request and receives the LMFA.
Step I: The IOP 42 examines the message header function to determine the type of message addressed by the LFMA. When the message is an SCSI IO request and the message is tagged as a request, the message is assigned a Qtag.
Step J: The IOP 42 posts a message index (MID) on the inter-processor IO request queue 44.
Step K: The CTX 48 polls an internal interrupt status register (i.e., the IO request queue 44) for a new request (i.e., MID).
Step L: The CTX 48 writes the message index MID into a context lookup table and writes a copy of the message to the SCSI core IO bucket 50.
Step M: The CTX 48 completes the IO by posting the unmodified MID on the IO completion queue 46.
Step N: When an error in the IO flow is indicated, the CTX 48 sets an exception bit in the MID indicating the message frame 40 has error status data. The IOP 42 polls the IO completion queue 46 interrupt status register and receives the MID.
Step O: When successful IO flow is indicated, the IOP 42 posts an unmodified message context to the reply FIFO 52 using a function bit in the MID to determine which function to implement.
When an error in the IO flow has been indicated, the IOP 42 presents (i.e., direct memory accesses) a reply frame to a host reply buffer and posts an RFD to the reply FIFO 52.
Step P: The IOP 42 frees the LMFA in the free FIFO 38.
Step Q: The host OS driver 12 receives an interrupt message (INTERRUPT) for a reply.
The IOP 42 performs an intermediary function between the OS driver 12 and the CTX managers 48a and 48b. During a normal mode of operation, the IOP 42 (i) continually receives IO requests from the OS 12, (ii) presents the IO requests to the CTX managers 48, (iii) receives IO completions from the CTX managers 48, and (iv) presents the IO completions to the OS 12.
The IOP 42 includes firmware that is polling based. The IOP 42 firmware has a tight polling loop that polls the IOP 42 interrupt status register. The IOP 42 firmware checks the bits in the IOP 42 interrupt status register in order of priority. When a particular bit is set in the IOP 42 interrupt status register, the IOP 42 performs the corresponding task.
However, some specific tasks (or interrupts) (i.e., system request FIFO interrupt and the inter-processor IO completion interrupt) frequently have problems. When the IOP 42 reads the interrupt status register, both the request and the completion bits in the interrupt status register can be set. The IOP 42 firmware is priority based. The IOP 42 firmware first determines the status of the request FIFO 34 and then determines the status of the completion queue registers 46. The IO controller 16 will start all the pending IO functions on the FIFO 34 before completing any of the IO functions on the completion queue 46. However, the controller 16 can have more IO functions to complete than to start (i.e., the completion queue and the request queue IO loads are unbalanced). Conventional controllers (i) start new IO requests before the completed IO messages (or functions) are finished, (ii) ignore the relative loads of the completed and the requested IO functions, and (iii) hinder overall performance and IO throughput.
It would be desirable to have an architecture and/or method for controllers that (i) dynamically balances request and completion queuing and/or (ii) efficiently determines IO request and completion priorities based on load.